Today, more and more software developers are choosing to write distributed transactional applications for the enterprise and leverage the speed, security, and reliability of server-side technology. Such distributed enterprise applications typically have to be designed, built, tested, and produced quickly, inexpensively, and with fewer resources than ever before. To reduce development costs and reduce enterprise application design and development time, various component-based platforms and approaches to the design, development, assembly, and deployment of enterprise applications have been developed.
Chief among these platforms are the Java 2 Platform, Enterprise Edition™ (J2EE) (more recently named the Java Platform, Enterprise Edition™ (Java EE)) from Sun Microsystems, Inc.™, and the .NET platform for web services and applications development from Microsoft Corporation™.
In general, such distributed application platforms provide a set of coordinated specifications and practices that together enable solutions for developing, deploying, and managing multi-tier server-centric applications. These platforms use object-oriented technology and a component-based approach to the design, development, assembly, and deployment of enterprise applications. Typical features include multitiered distributed application models, the ability to reuse components, a unified security model, and flexible transaction control.
The ability to develop software components that can be written once and re-used many times (in many different applications) means that reliability of component functionality is very important. Ensuring the integrity of the component product through thorough and high quality testing is therefore critical to developers. A common approach to assuring software quality is to perform extensive quality assurance testing QA late in the development process to test the end product. However, this approach can be counterproductive when testing component based systems. For example, defects in a software component that is used several different places in a distributed application can manifest themselves in numerous different ways, making it very difficult to trace the source of the defect back to the defective component. In short, quality cannot be ensured on a consistent basis unless testing is part of multiple stages in the development process.
Still another problem with software component testing is the complexity inherent in many prior art test techniques. For example, many software testing tools require users to develop complex testing scripts, include instrumentation code in the code to be tested, or otherwise require in-depth knowledge of the code under test. This typically means that fewer people can be involved in testing, e.g., those who authored the code under test are the only ones with sufficient knowledge or experience to use existing test tools. Moreover, because these prior art tools require authoring of some sort of code or script based testing logic, there is an increased likelihood that the testing software itself will have defects introduced in the authoring process.
Accordingly, to make testing part of multiple stages in the development process, simpler tools are desirable. Moreover, it is desirable to have tools that allow complex testing of software components without the need for extensive programming experience or the generation of complex testing code or scripts.